InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/inet/ietf/ipidrp/92nov.min

Text File | 1993-02-17 | 7KB | 187 lines

CURRENT_MEETING_REPORT_

Reported by Sue Hares/Merit

Minutes of the OSI IDRP for IP over IP Working Group (IPIDRP)

John Krawczyk responded to Sue Hares' request for volunteers to work
with her on MIB issues.

A merger of the IDRP-IP and BGP4 Working Group meetings was proposed.
There was consensus that this would be a good idea.  It was strongly
emphasized by a number of those present that BGP is not going to
suddenly disappear, simply that it would not be evolved past BGP4 (and
that further interdomain protocol work would go into IDRP instead).  No
one is being forced to transition to IDRP!

Dave Katz gave a status report on the ISO process for IDRP. In summary:


   o October 21st DIS ballot closes April 21, 1993.  The DIS text is
     available from the FTP archive on merit.edu (/pub/iso/idrp.ps).
     U.S. ballot comments are pending an ANSI meeting in January.

   o Specific issues expected to be addressed in the U.S. ballot
     comments are specification of protocol-specific data formats (this
     is somewhat CLNP-centric in the current DIS) and some state machine
     bashing.
   o Barring substantial technical objections to the DIS an IS text will
     be issued at the September SC6 meeting in Korea.


Dave Katz gave a quick IDRP tutorial.  (See slides for details?)

Discussion of IDRP-(other) Interactions.

In general, it seems that the IDRP interactions with other protocols are
virtually the same as for BGP4, and it may even be appropriate to adopt
entire BGP4 interaction documents (Sue will look into this).  (See
slides for further details of individual interactions?)

IDRP-EGP Interaction

A concern was raised regarding exploding large aggregate routes into
EGP. This isn't a bug per se, but text should be co-opted from the CIDR
document to warn against doing this.  A possible fix would be to allow
for the configuration of filters in the IDRP speaker to constrain
propagation of exploded info.

IDRP-BGP4

Bill Manning suggested that the Group ``clean up the verbiage.''  Tony
Li suggested that the document be revised to follow the BGP4-BGP3

                                   1





document.  Since there is little difference between the two, this can be
a short document.  The Group may specify that ARP should be used to get
SNPA of next-hop router.

IDRP-BGPx

In general, in an integrated IP/OSI IDRP environment, there needs to be
a way of mapping ASes back and forth into RDIs, and RDIs should be
assigned with this in mind.  The question arose of what to do with RDIs
which don't map cleanly into an AS, e.g., RDCs.  Options for this:


   o Don't propagate non-translatable RDIs.
   o Translate the RDI anyway (into what?)  and set the external-info
     flag.
   o Continue and syslog an error.


Another option (beyond the scope of BGP) would be to hand-configure a
list of RDC memberships into each BGP-speaker which is a member of an
RDC.

The usage document needs to clarify this issue.  Dave Katz volunteered
to work on this.

IDRP-OSPF

As for BGP4-OSPF. There was a great deal of debate on the subject of
using multiple exits from an RD to reach another RD, i.e., load-sharing.
Perhaps the IDRP-ISIS document needs to refine the mechanisms for this?
IDRP for IPAE/SIP was discussed.

Miscellaneous Items

Sue presented a list of don't/do implements.  (See slides for details.)

A glossary was proposed for the IDRP-IP document.  The example used was
``NLRI,'' which is never described in detail with respect to IP
addresses.

MIB and Policy.  Again, we can reference the analogous BGP4 document.

Additions to first Minutes from Dennis Ferguson

Issues to be resolved for BGP4 - idrp:


  1. What happens to unrecognized optional transitive attributes, both
     from BGP4->IDRP and from IDRP->BGP4.  (Editor's Note (sh):  The
     optional transitive attributes should be passed as unrecognized
     optional transitive attributes.  The bgp4-idrp document needs to
     note this.)

                                   2





  2. Clarification of Dual IDRP functions
     If domain's external IP connectivity is congruent to it's external
     CLNP connectivity, then the domain may have a single RDI for IP and
     CLNP and may run an integrated idrp.  In all other cases, the
     domain has to have two different RDIs and must run Ships in the
     Night protocol.  Ships in the Night protocol implies that one
     instances of the idrp protocols runs over IP and a second instance
     runs over CLNP.


Attendees

Lee Alley                [e-mail]
Nagaraj Arunkumar        [e-mail]
William Barns            [e-mail]
David Bolen              [e-mail]
Vickie Brown             [e-mail]
Ross Callon              [e-mail]
Brian Carpenter          [e-mail]
Richard Colella          [e-mail]
Michael Collins          [e-mail]
Dino Farinacci           [e-mail]
Dennis Ferguson          [e-mail]
Thomas Hacker            [e-mail]
Joel Halpern             [e-mail]
Juha Heinanen            [e-mail]
Robert Hinden            [e-mail]
Kathleen Huber           [e-mail]
David Jacobson           [e-mail]
Matthew Jonson           [e-mail]
Dave Katz                [e-mail]
Zbigniew Kielczewski     [e-mail]
Charley Kline            [e-mail]
John Krawczyk            [e-mail]
Padma Krishnaswamy       [e-mail]
Tony Li                  [e-mail]
Tracy Mallory            [e-mail]
Bill Manning             [e-mail]
David Meyer              [e-mail]
Robert Moose             [e-mail]
Dennis Morris            [e-mail]
John Moy                 [e-mail]
Andrew Partan            [e-mail]
Laura Pate               [e-mail]
April Richstein          [e-mail]
Dallas Scott             [e-mail]
John Scudder             [e-mail]
Paul Serice              [e-mail]
Frank Solensky           [e-mail]
Catherine Summers        [e-mail]
John Tavs                [e-mail]
Paul Traina              [e-mail]
Kannan Varadhan          [e-mail]

                                   3





Iain Wacey               [e-mail]
Luanne Waul              [e-mail]
Cathy Wittbrodt          [e-mail]



                                   4